做原型時，很容易把「又多了一個功能」當成進度，但功能越多，不一定代表作品越可靠。對我來說，真正不會歸零的 MVP，不是畫面最多、技術最新的版本，而是能明確說出它會做什麼、不會做什麼，而且任何人都可以按照相同步驟重新驗證的版本。今天我沒有替 CareCall AI 加入語音或 AI，而是停下來，把 Day 6 到 Day 17 累積的文字資料、規則分類與人工處理流程完整走過一次。

這次回歸從四位虛構個案開始。林阿春的四題資料完整，穩定得到「已完成」；陳明德的回答有缺漏與不確定內容，進入「待人工確認」，保存人工紀錄後才離開待辦；王秀蘭第一次沒有回應時維持「待提醒」，再次聯絡仍未回應才轉人工，而且重新整理後聯絡紀錄仍然存在；李春美明確表示不適並需要協助，因此得到「優先處理」，但這個狀態只安排工作順序，不代表醫療診斷或病情嚴重度。

我也逐頁檢查今日關懷總覽、個案詳細、關懷腳本設定、文字／語音關懷紀錄與待人工處理中心。五個畫面讀取同一份資料，人工紀錄完成後能同步更新，核心規則、錯誤備援與正式建置也都通過測試。這些證據比「畫面看起來正常」更重要，因為它們讓今天的結果可以在未來重複確認。

封存也代表誠實面對限制。目前的文字／語音關懷頁仍是唯讀 Demo，尚不能現場輸入回答；沒有真正的語音辨識、AI API、後端、帳號或跨裝置同步；規則只能處理經過定義與測試的有限句型。所有資料都是虛構內容，也不能拿來做醫療診斷或宣稱符合正式法規。把這些限制寫下來，不會讓 MVP 變得比較差，反而能避免未來誤以為功能已經完成。

今天建立的 v1.0-text-rule-mvp 是一條清楚的安全線。Day 19 之後可以在它上面加入語音與 AI，但不需要拆掉原本能運作的底座；如果新的實驗失敗，也能回到這個版本。所謂不會歸零，不是保證未來永遠不出錯，而是已經留下可執行的專案、可重複的測試、完整的限制與版本標籤，知道自己從哪裡出發，也知道必要時可以安全回到哪裡。